The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
As used herein, the term “data center” refers to a colocation of associated servers. The servers that belong to a particular data center are within the same building or complex but data centers are typically located geographically distant from each other. The geographic distance adds protection so that catastrophic failure in one data center caused by a natural disaster would not also cause failure in the other data center. For example, one data center might be located on the East Coast in New York and another data center might be located on the West Coast in San Francisco.
Global load balancing or “GLB,” is a mechanism for distributing client access to particular services across a plurality of servers. For example, in a situation in which a particular service is provided by servers that belong to data centers in New York and San Francisco, GLB might distribute client access so that the number of clients connected to the data center in New York is about the same as the number of clients connected to the data center in San Francisco.
When used in the context of the Internet, GLB may use a variety of active and passive monitoring techniques to generate a complex map of the Internet. Based upon this map, GLB makes traffic routing decisions to connect a client to the “closest” server. As used herein, “close” does not necessarily mean basing the determination only on geographic proximity. As used herein, a “close” server is a server that results in the fastest connection to the client. Thus, if a server that was located 100 miles away were slower for the client to reach than a server located 200 miles away because of heavy congestion, then GLB would route the client to the “closer” server that is 200 miles away.
If a user wishes to connect to a web application or a web page, a DNS request is made. A DNS request begins with a user making a request through a client machine, often by typing a domain (e.g. “www.sampledomain.com”) in a web browser. The request is sent from the client to a service provider's local DNS resolver (“LDNS”). An LDNS resolver accepts the request from the client and responds to the request with the domain's IP address if the LDNS resolver has stored the answer to the request in a cache. If the LDNS does not have the answer stored, the LDNS forwards the request to an authoritative DNS resolver. An authoritative DNS resolver is a server that maintains data for the network of a domain. The authoritative DNS resolver receives requests from a LDNS resolver and replies to the LDNS resolver with an IP address of a particular server to connect with the domain. As used herein, GLB resolvers may be a part of an authoritative DNS resolver. GLB resolvers may also be separate or located remotely from an authoritative name server. This may vary from implementation to implementation.
Unfortunately, GLB decisions may be based upon insufficient data. For example, if a request is made from the LDNS resolver to the GLB, the request contains information only about the LDNS and not the client that originated the request. Thus, the GLB is forced to make a decision based upon the location and congestion at the LDNS resolver rather than at the client.
Basing routing information on the LDNS resolver and not the client may cause two major problems. First, the client may be located very differently, by geography and network, than the LDNS resolver. This often leads to incorrect proximity mapping by the GLB. Second, because the LDNS resolver caches replies, the GLB is unable to determine the quantity of requests that are being generated by clients sitting behind the LDNS resolver. A single user performing a DNS lookup and one million different users may generate the same amount of traffic at the GLB. This makes load balancing determinations very inaccurate.
An example of GLB based upon DNS is illustrated in FIG. 1. In FIG. 1, two data centers, or colocations, are located in geographically distinct areas. One data center is located in New York 103 and the other data center is located in San Francisco 101. The data center in New York 103 has an IP address 1.2.3.4 and the data center in San Francisco 101 has an IP address of 2.2.2.2.
A client 105 wishes to connect to the web page, “www.sampleconnection.com,” hosted by the two data centers. The client 105, which uses ACME internet service provider, makes a request to connect to the domain. The request from the client 105 is sent 111 first to the ACME LDNS resolver 107. Based upon the request, the LDNS may have the answer stored in cache or forward the request to the domain's authoritative server that provides the IP address of the domain.
The ACME LDNS resolver 107 checks whether the IP address of the domain is stored in the LDNS resolver's cache. If the IP address is stored in the cache, then the stored IP address is sent to the client in response to the request. If the IP address to the domain is not found in the cache, then the LDNS resolver sends a request to the authoritative DNS resolver for the domain “www.sampleconnection.com” to obtain an IP address. This is shown in the request 115 made to the GLB and authoritative DNS resolver 109 for the domain “www.sampleconnection.com.”
The GLB (with the authoritative DNS resolver) 109 then determines, based upon the request for the web page, whether to return the IP address of 1.2.3.4 for New York or 2.2.2.2 for San Francisco. Logic in the GLB analyzes the request including the location where the request originated, and the availability and load of the servers to determine which particular server is best for a particular client.
Unfortunately, the authoritative DNS server 109 views the request as originating from the location of the ACME LDNS resolver 107 in North Carolina, and not from the location of the client 105 in Arizona. Based upon the information from the LDNS resolver 107, the authoritative DNS server 109 might select a connection server based upon a request from North Carolina and the much geographically longer path to New York 119 might be selected rather than the shorter path from the client 105 to San Francisco 117.
The authoritative DNS resolver 109 is also unable to determine the number of clients that may reside behind a LDNS resolver. A single request to the authoritative DNS resolver may actually be for many clients behind the LDNS resolver. For example, the ACME LDNS 107 might make a single request for client 105 for the domain. After the first request, the ACME LDNS 107 stores the IP address of the domain in cache. One second later, ten thousand more requests are made for the same domain. Because the IP address is stored in the LDNS resolver's cache, the IP address is automatically returned to the clients and no additional requests are sent to the authoritative DNS server, for a period of time specified by the Time To Live setting in the response. Thus, should a server become overloaded or fail and the authoritative DNS server and GLB 109 must transfer clients from the overloaded or failed server to a healthy server, the authoritative DNS server 109 is unable to determine the number of clients sitting behind the LDNS resolver 107 and proper load balancing may not be maintained.